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ABSTRACT 

This  research  assesses  the  impact  of  synchronous  (real-time),  text-based  chat  on  military 
command  and  control  (C2)  processes.  Chat  use  among  the  services,  particularly  among  joint 
forces,  has  evolved  in  ad  hoc  fashion  to  fill  gaps  in  currently  fielded  C2  systems.  This  growth- 
by-improvisation  inhibits  clear  definition  of  the  underlying  requirements:  precisely  what  C2 
deficiencies  are  being  addressed  by  text-based  chat  tools?  Or,  from  a  bottom-up  perspective: 
what  capabilities  do  text-based  chat  tools  bring  to  the  war  fighter?  In  this  study  we  employ  a 
broad  set  of  use-cases  to  further  refine  why  operators  use  chat  based  on  how  they  apply  chat  to 
their  specific  combat  problems.  These  use  cases  include  ongoing  combat  operations  in 
ENDURING  FREEDOM,  counter-insurgency  operations  in  IRAQI  FREEDOM,  and  disaster 
relief  operations  with  Joint  Task  Force  -  Katrina.  The  focus  of  this  study  is  on  establishing 
operators’  perceived  requirements  in  light  of  the  current  capabilities  delivered  by  the  existing 
text-based  chat  tools.  From  these  “reverse-engineered”  requirements  we  propose  future  work  to 
establish  these  communication  capabilities  in  the  next-generation  C2  systems. 
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INTRODUCTION 

Communication  is  the  essence  of  C2,  and  the  availability  of  real-time,  text-based 
communications  tools  has  led  to  a  proliferation  of  ad  hoc  “solutions”  for  the  warfighter. 
Currently  within  the  services,  every  command  appears  to  have  its  own  preferred  text-based  chat 
client.  While  these  solutions  fill  short  term  requirements,  they  usually  miss  the  mark  of  joint 
interoperability.  No  standardized  text  chat  tool  for  C2  has  led  to  confusion  and  an  inability  to 
interoperate.  No  official  text-based  chat  requirements  document  exists  for  any  of  the  services 
nor  is  there  an  official  joint  chat  requirements  document.  Further,  there  is  no  official  support  for 
text-based  chat  from  the  services’  program  offices.  In  effect,  within  the  U.S  military  there  is  a 
tool  used  extensively  for  C2  with  no  official  requirements,  no  official  support,  and  no  official 
sponsorship. 

This  paper  first  assesses  the  impact  of  synchronous  (real-time),  text-based  chat  on 
military  command  and  control  (C2)  processes.  Operational  chat  usage  is  documented  across  the 
warfighting  functions  and  the  full  spectrum  of  military  operations  with  a  brief  selection  of  use 
cases  from  Eovito  (2006).  The  current  trend  in  chat  research  focuses  on  the  technical  aspects  of 
chat  based  off  anecdotal  evidence,  both  of  which  serve  to  obscure  development  of  a  coherent 
problem  statement.  This  research  consolidates  specific  cases  of  chat  use  to  better  develop  insight 
into  the  problem,  catalog  capability  gaps,  and  generate  high-level  requirements. 

There  is  risk  associated  with  various  chat  tools  and  protocols.  Technical  risks  are  the 
most  documented  by  organizations  like  the  Defense  Information  Systems  Agency  (DISA).  In 
this  paper,  we  assess  not  only  technical  risks,  but  other  risks  that  are  very  difficult  to  assign 
metrics  to,  like  those  related  to  organization,  human  nature,  situational  awareness,  and  perhaps 
most  interestingly,  the  impact  of  chat  use  on  other  C2  methods. 

We  finish  with  an  explanation  of  the  methodology  used  for  documenting  and  developing 
the  chat  requirements.  The  quad-service  chat  requirements  and  select  Combatant  Command 
(COCOM)  requirements  from  Eovito  (2006)  are  listed  as  appendices.  These  high  level 
requirements  decompose  the  chat  problem  to  a  level  that  users,  engineers,  and  managers  alike 
can  use,  discuss,  and  understand.  Erom  this  common  understanding  all  stakeholders  can  work 
together  to  develop  a  set  of  combined  and  joint,  text-based  chat  requirements  for  the  next- 
generation  C2  systems. 
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BACKGROUND 

Modern  chat  tools  allows  multiple,  concurrent  users  real-time  participation  in  multiple 
chat  channels  (chat  rooms).  The  conversations  within  these  channels  are  referred  to  as  threads. 
The  use  of  client-server  architecture  provides  the  ability  to  scale  a  population  of  users  from  a  few 
locally  to  thousands  globally.  Internet  Relay  Chat  (IRC)  is  one  of  the  most  widely  used  chat 
protocol  for  military  C2  (Boettcher  2005;  Duffy  2005).  This  study  considers  chat  usage 
regardless  of  type,  whether  chat  specific  tools  like  mIRC  or  Microsoft  Chat  (MS  Chat)  or 
embedded  chat  functionality  found  in  many  C2  systems  and  collaborative  suites  like 
InfoWorkSpace  (IWS). 

Chat  use  by  the  military  grew  rapidly  during  Operation  Enduring  Freedom  (OEF)  and 
Operation  Iraqi  Freedom  (OIF).  Not  only  did  chat  usage  grow  on  its  own,  we  saw  chat  usage 
grow  to  supplement  (or  in  some  cases  replace)  other  C2  systems.  The  experiences  of  the  United 
State  Navy  and  the  United  States  Central  Command  (USCENTCOM)  illustrate  this. 

Early  during  OEF  there  was  one  IRC  server  in  the  Navy’s  Fifth  Fleet  that  averaged  300 
concurrent  chat  users  (Banerjee  2005).  Chat  use  soon  overcame  capacity  and  a  second  IRC 
server  was  installed  in  Fifth  Fleet  supporting  approximately  500  concurrent  users  (Banerjee 
2005).  Chat  use  grew  drastically  during  OIF  and  two  more  IRC  servers  installed,  bringing  the 
totals  to  four  servers  supporting  approximately  2500-3000  concurrent  users  in  350-400  chat 
channels  (Banerjee  2005;  Heacox  2004). 

Prior  to  OIF,  USCENTCOM  used  the  Defense  Collaborative  Tool  Suite  (DCTS)  chat 
programs  during  exercises  in  Saudi  Arabia;  however,  DCTS  provided  inadequate  chat  capability 
(no  multiple  room  support)  and  USCENTCOM  J6  made  the  switch  to  IWS  (Jara  and  Fisowski 
2003).  The  bandwidth  requirements  of  chat  with  IWS  created  latency  problems  and 
USCENTCOM  switched  to  the  US  Naval  Forces  Central  Command’s  (USNAVCENT)  four  IRC 
servers  in  Bahrain,  which  continue  supporting  all  areas  of  operations  (Banerjee  2005;  Jara  and 
Fisowski  2003).  Currently  servers  at  USNAVCENT,  A1  Udeid  Airbase  in  Qatar,  HQ 
USCENTCOM,  and  DISA  support  the  following  chat  clients:  mIRC,  MS  Chat,  JABBER,  and  IE 
Web  Browser  clients  (Moore  2005). 

Users  rapidly  realized  text  chat  was  a  mission  essential  C2  tool  and  discussion  grew 
about  the  lack  of  official  requirements,  official  support,  and  official  sponsorship.  The  Navy’s 
program  office.  Space  and  Naval  Warfare  Command  (SPAWAR)  reacted  first.  In  response  to 
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the  Navy’s  text  ehat  needs,  Joint  Distributed  Command  and  Control  Technologies  SSC-SD, 
SPAWAR  Systems  Center  San  Diego  (SSC-SD)  hosted  the  1st  Annual  Internet  Relay  Chat 
(IRC)  Conference  in  2004.  All  four  services,  numerous  COCOMs,  and  Other  Government 
Agencies  (OGA)  attended.  This  conference’s  purpose  was  to  identify  chat  users  and  provide 
support  to  them  throughout  the  Department  of  Defense  (DoD).  While  focused  on  IRC  protocol- 
based  chat  tools,  this  conference  supported  users  of  all  chat  tools,  discussed  emerging 
technologies,  and  the  way  forward  within  DoD.  The  2nd  Annual  IRC  Conference  was  held  in 
June  2005  and  was  again  attended  by  all  four  services,  numerous  COCOMs,  and  OGAs. 

During  the  June  2005  conference.  Joint  Distributed  Command  and  Control  Technologies 
SSC-SD  was  tasked  with  developing  the  joint  chat  requirements  for  a  Joint  Resource  Oversight 
Council  (JROC)  package  by  Joint  Chiefs  of  Staff  J-6  (JCS-J6)  and  Office  of  the  Assistant 
Secretary  of  Defense  for  Networks  and  Information  Integration  (ASD(NII)).  The  research  in  this 
paper  is  part  of  that  effort. 

USE  CASES 

The  warfighter  has  expanded  the  role  of  chat  across  the  full  spectrum  of  military 
operations.  Commanders  and  innovative  operators  at  all  levels  and  units  have  grown  their  own 
chat  solutions  to  complex  C2  problems  despite  the  many  systems  fielded  to  solve  the  same.  Chat 
is  used  by  the  warfighter  to  put  steel  on  target,  or  conversely,  to  build  schools  and  repair 
mosques.  These  operational  examples  are  intentionally  broad  to  provide  a  brief  yet  substantive 
illustration  of  the  far-reaching  use  of  chat  for  military  C2. 

A.  J-3  OPERATIONS 

1,  Multinational  Operations 

Her  Majesty’s  Canadian  Ship  (HMCS)  TORONTO  (FFH-333)  participated  in 
OPERATION  ALTAIR  (Canadian  OEF  parallel)  in  2004.  She  deployed  as  a  fully  integrated 
escort  of  the  USS  GEORGE  WASHINGTON’S  (CVN-73)  Carrier  Strike  Group  (CSG)  to  the 
Arabian  Gulf. 

The  CSG  exercised  C2  with  chat  over  SIPRNET  (Secure  Internet  Protocol  Routed 
Network),  which  HMCS  TORONTO  (the  CSG’s  only  foreign  ship)  could  not  access.  Canadian 
Eorces  task  by  voice;  however,  the  CSG  used  the  coalition  wide  area  network  (COWAN)  chat 
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for  tasking  HMCS  TORONTO,  with  voice  circuits  as  backup.  United  Kingdom  and  New 
Zealand  vessels  in  the  area  of  operations  (AO)  were  also  on  COWAN  ehat. 

TORONTO  stood  picket  duty  in  sector  screen  for  the  CSG,  tasked  and 
coordinated  over  COWAN  ehat.  Tasking  orders  for  urgent  maritime  interdiction  operations 
(MIO)  were  sent  to  HMCS  TORONTO  over  the  COWAN  chat  and  she  boarded  123  ships  for  the 
CSG. 

The  Combat  Officer,  HMCS  TORONTO  summed  up  chat  issues  from  the 
Canadian  point  of  view.  The  U.S.  Navy  did  not  rely  on  a  single  ehat  tool  for  C2.  With  HMCS 
TORONTO  as  the  only  non-U. S.  warship  it  was  easy  for  the  CSG  to  overlook  the  need  to  use 
COWAN  chat.  Even  with  a  liaison  officer  (LNO)  aboard  the  George  Washington  and  six 
months  together,  the  U.S.  never  made  the  leap  to  using  COWAN  and  eontinued  using  primarily 
SIPRNET  ehat.  The  recommendation  was  that  coalition  forces  should  use  eoalition  networks. 

2,  Disaster  Relief  Operations/Civil  Military  Operations 

Amphibious  Squadron  Eour  (PHIBRON4),  embarked  aboard  the  USS  IWO  JIMA 
(EHD-7),  used  chat  for  C2  during  humanitarian  operations  with  Joint  Task  Eorce-Katrina  (JTE- 
Katrina).  Chat  was  used  extensively  to  plan,  task,  and  coordinate  pre-deployment  and  underway. 
Upon  arrival  in  New  Orleans,  the  movement  of  amphibious  craft  for  transporting  personnel, 
equipment,  and  supplies  ashore  was  eoordinated  and  tracked  through  chat.  Situation  Reports 
(SITREPs)  from  the  ships  and  detachments  ashore  were  sent  to  PHIBRON4  with  ehat  and  then 
sent  from  PHIBRON4  to  Amphibious  Group  2  (PHIBGRU2)  by  the  same  means.  After 
Hurricane  Rita,  the  USS  TORTUGA  (ESD-46),  in  Cameron,  Eouisiana,  passed  information  on 
its  amphibious  eraft  operations  and  SITREPs  over  chat  to  PHIBRON4,  still  embarked  on  the 
USS  IWO  JIMA  in  New  Orleans. 

Canada  executed  Operation  UNISON  in  response  to  Hurricane  Katrina,  sending 
its  East  Coast  Task  Group,  including  HMCS  TORONTO  (EEH-333),  to  Biloxi,  Mississippi 
during  September  and  October  of  2005.  Operations  were  reported  to  the  USS  Saipan  using 
Maritime  Command  Operational  Information  Network  (MCOIN)  chat  (MCOIN  facilitates 
Canadian  maritime  C2  with  U.S.  Navy).  The  Canadian  Task  Group  requested  and  coordinated 
landing  support  for  its  engineers,  wood,  generators,  and  other  supplies  over  MCOIN  chat. 

United  States  Marine  Eorces  Atlantie  (USMAREORLANT)  recognized  a  gap  in 
its  C2  capability  during  JTE-Katrina  operations.  The  USMAREORLANT  lessons  learned  from 
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JTF-Katrina  included  one  entitled  “Real  Time  Information  Dissemination.”  Watch  Officers  had 
difficulty  disseminating  timely  information  with  email.  Citing  successful  chat  usage  in  OIF  for 
the  conduet  of  fire  [fire  support]  and  unmanned  aerial  vehicle  (UAV)  operations,  it  was 
reeommended  that  USMARFORLANT  establish  chat  rooms  to  support  real  time  information 
dissemination  (Gray  2005). 

The  Area  of  Responsibility  (AOR)  for  the  U.S.  Southern  Command 
(USSOUTHCOM)  is  a  huge  geographic  area  where  disaster  relief  efforts  are  not  uncommon  and 
civil  military  operations  (CMOs)  are  the  norm.  Headquarters  USSOUTHCOM  uses  the  ehat 
capabilities  of  DOTS  to  eoordinate  and  support  CMOs  in  its  AOR.  Chat  was  used  to  coordinate 
disaster  relief  efforts  for  the  flooding  in  Guatemala  caused  by  Hurricane  Stan  in  2005. 

3.  Antiterrorism/Homeland  Defense 

An  antiterrorism  vignette  from  Commander  Coast  Guard  District  14  message 
162008Z  MAY  03,  After  Action  Report:  Terrorism  Threat  on  Board  Cruise  Ship  Legend  of  the 
Seas  (LOS),  22-24  April  03: 

On  22  April  2003  Royal  Caribbean  Cruise  lines  cruise  chip  Legend  of  the  Sea  (LOS)  was 
en  route  from  Ensenada,  Mexico  to  Hilo,  Hawaii  for  a  scheduled  port  call  with  1668 
passengers  and  701  crewmembers.  A  eleaner  found  a  written  note  in  a  restroom 
threatening  the  lives  of  American  passengers  onboard.  LODS  reported  the  note  to  Royal 
Caribbean  Cruise  Lines  who  informed  the  National  Response  Center  (NRC)  and  the 
Federal  Bureau  of  Investigation  (FBI).  Captain  of  the  Port,  Honolulu,  ordered  LOS  to 
not  enter  port  and  divert  to  anchorage  offshore.  A  123  member  multi-ageney  boarding 
was  eonducted  to  seeure  and  clear  LOS  (D14  2003). 

Coast  Guard  District  14  (D14)  assumed  Lead  Federal  Agency  (LFA)  for  the 
boarding  and  operated  in  two  SIPRNET  chat  rooms  that  included  USCG  Paeific  Area,  US 
Paeific  Command  (USPACOM),  Commander  U.S.  Paeific  Elect,  and  93rd  Weapons  of  Mass 
Destruction  Civil  Support  Team  (93rd  WMD-SCT). 

A  Marine  Corps  Visit,  Board,  Search  and  Seizure  (VBSS)  vignette  from  the  2003- 
2004  deployment  of  the  13th  Marine  Expeditionary  Unit  (MEU)  Special  Operations  Capable 
(SOC)  in  the  Arabian  Gulf: 

The  Maritime  Special  Purpose  Eorce  (MSPE)  Commander  is  aboard  the  shouldering  ship 
with  laptop  and  chat  connectivity.  The  Eorce  Platoon  Commander  is  on  the  boarded 
vessel.  They  were  in  contact  over  voice  radio,  but  the  MSPE  Commander  was  in  contact 
with  the  Eanding  Eorce  Operations  Center  [EEOC]  aboard  a  US  Navy  amphibious  ship 
using  chat.  Prowords  for  mission  segments,  information  requests,  and  the  unfolding 
mission  were  passed  and  tracked  in  chat.  The  EPOC  passed  additional  tasking  to  the 
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MSPF  as  the  mission  progressed.  The  VBSS  resulted  in  the  seizure  of  hashish  with  an 
estimated  value  in  the  millions. 

4,  Special  Operations 

In  2002  and  2003,  during  OEF  in  Afghanistan,  units  from  Third  Special  Forces 
Group  (Airborne)  operated  widely  dispersed  as  part  of  the  Combined  Special  Operations  Task 
Force  (CJSOTF).  Third  Group  was  equipped  with  AN/PSC-5  Satellite  Radios,  but  assigned  a 
single  voice  satellite  communications  (SATCOM)  channel  shared  by  the  entire  CJSOTF  within 
the  theater  and  reserved  for  command,  emergencies,  or  units  in  contact.  The  SATCOM  radios 
were  data  capable  with  ruggedized  laptops  allowing  Special  Forces  teams  to  send  free  text 
messages.  This  is  significant,  because  despite  not  having  an  actual  chat  tool,  units  used  the  free 
text  messaging  capability  to  provide  an  improvised  chat  (more  specifically  instant  messaging) 
functionality  to  fill  the  C2  gap.  Army  Special  Forces  firebases  always  had  SATCOM 
connectivity  with  the  text  messaging  capability  running  and  most  business  within  the  firebases 
was  conducted  by  text  conversations.  While  on  the  move  during  operations,  teams  were 
contacted  over  voice  SATCOM  and  told  to  come  up  on  the  laptops  for  text  messaging. 

One  Special  Forces  Operational  Detachment  A  (ODA)  Commander  recounted 
how  this  text-based  communications  capability  aided  operations.  His  ODA  team  was  operating 
in  an  area  where  another  unit’s  mission  fell  through.  His  team  received  a  voice  call  over 
SATCOM  to  come  up  on  SATCOM  data.  With  the  text  messaging  capability  he  received  a 
fragmentary  order  (FRAGO),  acknowledged  receipt,  and  discussed  operational  details.  This 
improvised  chat  capability  allowed  the  ODA  team  to  execute  the  FRAGO  much  more  rapidly 
than  if  a  voice  exchange  had  taken  place.  The  ODA  executed  a  cordon  and  search  of  a  small 
village,  resulting  in  two  personnel  under  control  (PUCs  -  enemy  combatants;  not  prisoners  of 
war)  and  capture  of  a  weapons  cache.  The  SITRFP  was  sent  to  higher  headquarters  using  the 
improvised  chat  capability,  which  would  read  it  and  start  asking  questions  back. 

In  another  case,  after  mission  completion,  an  ODA  team  sent  a  SITRFP  to  higher 
headquarters  using  the  improvised  chat.  The  CJSOTF  replied  immediately  concerning  the  PUCs 
the  ODA  had  in  custody.  The  ODA  Commander  replied,  telling  the  CJSOTF  when  and  where 
the  Afghan  Militia  Forces  (AMF)  captured  the  PUCs,  passed  their  descriptions,  what  PUCl  and 
PUC2  said  when  debriefed,  and  that  they  had  dual  identification  that  did  not  check  out.  He  also 
reported  that  they  had  weapons  and  were  seen  leaving  a  large  cache  with  rifle  propelled  grenades 
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(RPGs),  Soviet  style  mines,  detonation  eord,  ete.  Information  eontinued  to  be  passed  and  then 
the  CJSOTF  direeted  the  ODA  team  to  maintain  positive  eontrol  of  the  PUCs  and  doeument  all 
information  about  them.  The  total,  detailed  exehange  required  only  a  eouple  of  minutes  with  the 
improvised  ehat. 

5,  UAV  Operations 

Sixth  Marine  Regiment  used  ehat  for  global  eollaboration  during  Direet  Support 
(DS)  UAV  operations.  Sixth  Marines,  in  Afghanistan  for  OEF,  used  ehat  to  eommunieate  with 
the  Air  Foree  UAV  pilot  and  payload  operator  at  Nellis  Air  Foree  Base  (AFB),  Nevada.  During 
the  UAV  mission,  the  regiment  requested  speeifie  aetions  by  the  pilot  and  the  payload  operator 
in  real  time,  while  the  Army  Colleetion  Manager  for  the  CJTFs  monitored  the  ehat  room  and 
traeked  the  mission. 

Seeond  Battalion,  Fifth  Marines  (2/5)  used  chat  for  UAV  operations  in  OIF  I  and 
OIF  II.  Chat  allowed  2/5  to  direct  the  pilot  and  the  payload  operator  during  the  mission  and 
disseminate  what  the  UAV  was  seeing. 

Marine  Unmanned  Aerial  Vehicle  Squadron  Two  (VMU-2)  used  chat  extensively 
during  OIF  II  and  OIF  III.  Chat  was  used  for  UAV  support  to  targeting,  strike  execution,  and 
close  air  support  (CAS)  for  units  supported  by  VMU-2  UAVs. 

6.  Targeting 

Third  Infantry  Division  (SID)  OIF  targeting  vignette: 

“Baghdad... watched  a  BM-2I  moved  to  outskirts  of  city  S/SE;  fires  3-5rounds,  returns  to 
city.  SID  following  on  UAV  (in  DS  to  DIV)  and  tracks  launcher  back  into  the  city  where 
launcher  links  with  re-supply  vehicle.  96D  SGT  HOFT,  Paul  is  watching  on  GBS 
[Global  Broadcast  System]  monitor  and  is  in  mIRC  Chat  talking  to  Air  Force  FAC 
[Forward  Air  Controller]  while  the  Targeting  Officer,  IFT  Elizabeth  Snyder  is  talking  to 
CFACC  [Combined  Force  Air  Component  Commander]  in  parallel.  SGT  Holt  verifies 
grid  and  confirms  target.  Air  force  destroys  target.  Total  time  of  sensing  to  shooter  -  20 
minutes... would  have  been  earlier  but  he  [BM-21]  was  driving  in  residential  area... ACE 
did  not  see  the  re-supply  vehicle  in  the  field  he  drove  into  until  the  BM-21  stopped  at  its 
hide  site”  (Bell,  Gainey,  and  McCoy  2003). 

The  US  Air  Force’s  421st  Fighter  Squadron  used  SIPRNET-based  chat  for  time 
sensitive  targeting.  This  allowed  collaboration  with  the  Combined  Air  Operations  Center 
(CAOC)  at  A1  Udeid  Airbase  for  questions  on  targets,  the  ATO,  or  strike -related  questions  and 
coordination  with  parallel  agencies.  Dynamic  targeting  and  strikes  were  also  facilitated  by  chat. 
For  example,  a  ground  unit  calls  in  a  troops  in  contact  (TIC)  report,  the  information  flows  to 
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squadron  operations,  which  can  then  re -task  aircraft  to  collect  targeting  intelligence  or  to  execute 
CAS.  This  applied  to  situations  beyond  troops  in  contact  like  pipeline  attacks  or  suspicious 
activity  where  jets  from  the  421st  would  be  re-tasked  to  a  specific  target  for  surveillance.  The 
squadron  monitored  the  mission  and  watched  the  CAOC  direct  events.  Monitoring  the  mission 
in  chat  aided  in  debrief  preparation  and  expedited  the  debrief/mission  report  process  once  the 
pilots  returned. 

7.  Close  Air  Support 

During  OIF  the  4th  Air  Support  Operations  Group  (4th  ASOG)  attached  to  the  US 
Army  V  Corps  used  chat  continuously  for  CAS  execution  among  US  Army  V  Corps,  Coalition 
Land  Forces  Component  Command  (CFLCC),  Combined  Force  Air  Component  Commander 
(CFACC),  and  Marine  Expeditionary  Forces  (MEF).  They  provided  C2  for  all  CAS  V  Corps 
CAS  missions  and  considered  chat  absolutely  critical  to  mission  accomplishment  because  it  was 
the  most  expedient  method  of  communication  and  allowed  real-time  collaboration. 

Chat  was  used  by  4th  ASOG  to  task  UAVs  (Predator,  Hunter,  Shadow,  Global 
Hawk)  and  other  assets  to  collect  and  disseminate  intelligence  to  Tactical  Air  Control  Parties 
(TACP),  CAS  aircraft,  V  Corps  ACE  (Analysis  and  Control  Element),  and  any  other  units 
requiring  the  information  for  CAS  execution.  Chat  was  further  used  for  de-confiiction  of  CAS, 
joint  fire  support,  and  of  CAS  and  UAV  airspace,  real-time,  within  V  Corps,  MEE,  CEACC, 
UAV  units,  and  Air  Eorce  Distributed  Ground  Stations  (AE  DGS)  -  the  people  exploiting  UAV 
imagery. 

The  22d  MEU  (SOC)  in  Afghanistan  for  OEE  coordinated  details  of  emergency 
CAS  tasking  over  chat,  mainly  for  the  requesting,  allocating,  and  tasking  stages.  The  senior 
watch  officer  would  post  TIC  reports  in  the  main  chat  room  and  CAS  details  would  be  worked 
out  in  the  same  room  or  in  private  chat  with  liaison  officers  at  CJTE-76  ACCE.  Changes  to  chat 
were  discussed  in  chat  before  and  during  the  mission.  Changes  would  be  sent  to  coordinating 
agencies  in  chat  and  from  there  radioed  to  airborne  aircraft.  The  Marine  Direct  Air  Support 
Center  (DASC)  used  chat  to  update  what  aircraft  would  execute  CAS  and  their  status  (i.e. 
tanking,  time  remaining  on  station). 

8,  Combat  Recovery 

The  421st  Tighter  Squadron  used  chat  extensively  in  every  combat  search  and 
rescue  (CSAR)  mission  during  OIE  (Eovito  2006).  Chat  was  the  primary  tool  used  with 
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UHFA^HF  voice  circuits  for  airspace  de-confliction  and  other  supporting  arms  and  coordination 
of  close  air  support  (CAS)  for  combat  recovery  missions.  The  24th  MEU  (SOC)  used  chat 
during  OIF  I  and  OIF  II  to  request  aircraft  for  combat  recovery  missions  and  pass  information. 

Helicopter  Anti-Submarine  Squadron  Three  (HS-3  “TRIDENTS”)  embarked 
aboard  the  USS  ENTERPRISE  (CVN-65)  for  OEE,  used  chat  for  joint  CSAR.  The  TRIDENTS 
supported  joint  maritime  CSAR  and  CSAR  for  western  Pakistan  and  southern  Afghanistan. 

Chat  was  also  used  for  search  and  rescue  missions  (SAR)  in  the  United  States. 
Again,  HS-3  used  chat,  this  time  to  coordinate  a  joint  Navy  and  Coast  Guard  maritime  rescue  off 
of  North  Carolina. 

9,  Medical  Evacuation 

Chat  played  a  significant  role  in  the  medical  evacuation  (MEDEVAC)  process 
around  the  world  and  across  the  spectrum  of  military  operations.  Chat  was  used  in  Afghanistan 
during  OEE  by  CJTF-180  to  coordinate  MEDEVACS  of  combat  and  non-combat  casualties.  The 
CJTF  also  used  chat  to  clear  fires  in  the  MEDEVAC  airspace.  The  22nd  MEU  (SOC)  also  used 
chat  for  MEDEVACS  as  part  of  CJTF-180  and  later  CJTF-76  in  Afghanistan  during  OEF.  Units 
posted  MEDEVAC  nine  lines  to  the  main  chat  room  and  the  MEU  would  either  task  our  organic 
air  with  the  MEDEVAC  over  chat  or  use  chat  to  request  support  from  higher  headquarters. 
When  Third  Battalion,  Sixth  Marines  (3/6)  received  a  unit  in  contact  report  they  immediately 
monitored  the  MEDEVAC  preparations  in  the  aviation  brigade’s  chat  room  and  passed 
MEDEVAC  information  to  the  CJTF  in  chat. 

During  two  deployments  to  Iraq,  Helicopter  Marine  Heavy  Squadron-465  (HMH- 
465)  received  tasking  from  higher  to  execute  MEDEVACs.  The  9-line  (MEDEVAC) 
information  was  passed  to  the  squadron  over  chat  and  then  handed  to  the  MEDEVAC  pilot  just 
prior  to  launch.  This  information  included  grid  coordinates,  radio  frequencies,  what  to  expect  at 
the  landing  zone  (LZ),  etc. 

Chat  was  also  used  to  coordinate  MEDEVACs  during  Disaster  Relief  Operations. 
The  USS  IWO  JIMA  used  chat  to  coordinate  MEDEVACs  as  part  of  JTF-Katrina 

10.  Meteorological  and  Oceanographic  Support  to  Joint  Operations 

Meteorological  and  oceanographic  (METOC)  forecasting  support  affects  joint  and 

combined  operations  across  the  full  military  spectrum.  Chat  has  proven  a  vital  tool  for 
coordinating  weather  forecasts  for  various  theaters.  Southern  Command  METOC  (J332) 
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personnel  used  chat  during  Operation  SECURE  TOMORROW  to  coordinate  weather  support  for 
Royal  Canadian  Air  Eorce  helicopters  flying  in-and-around  Port-au-Prince,  Haiti. 

The  28th  Operational  Weather  Squadron  (OWS)  at  Shaw  Air  Eorce  Base  (AEB),  South 
Carolina  used  chat  to  support  OEE/OIE.  With  chat  they  conducted  forecast  coordination, 
tailoring,  and  dissemination  to  in-theater  units  from  one  platform. 

The  lack  of  weather  data  in  Iraq  complicated  forecasting  efforts,  but  with  chat  METOC 
units  at  the  CAOC,  A1  Udeid  Airbase,  Qatar  and  others  spread  throughout  Iraq  could  collaborate 
with  each  other  and  with  the  regional  forecasting  center  at  Shaw  AEB.  The  collaboration 
enabled  by  chat  enabled  them  to  develop  one  general  forecast  for  the  entire  theater. 

US  Central  Air  Eorces  Command  (USCENTAE)  METOC  used  chat  to  provide  weather 
support  to  all  four  services  in  both  the  OEE  and  OIE  theaters.  Chat  was  used  to  communicate 
with  units  in  the  field  and  discuss  weather  products.  These  units  in  the  field  were  able  to  act  as 
“eyes  forward”,  feeding  weather  information  back  to  USCENTAE  that  was  integral  to  their 
product  construction.  They  found  chat  use  provided  a  more  constant  and  reliable  flow  of 
information  than  other  available  methods  (i.e.  phone,  email).  With  chat  they  were  able  to 
provide  the  best-tailored  weather  products  to  units  because  chat  provided  access  to  most  units, 
enabling  efficient,  multi-person  discussions  that  affected  large  groups  of  people.  The  time- 
sensitivity  of  some  weather  products  was  met  with  chat,  which  proved  the  fastest  and  most 
reliable  method  for  their  dissemination. 

B,  J-2  INTELLIGENCE 

1.  Counterintelligence 

Members  of  the  Air  Eorce  Office  of  Special  Investigations  (AEOSI)  Detachment 
105,  Robins  AEB,  Georgia  provide  real  time  counterintelligence  support  in  the  Metro-Atlanta 
and  middle  Georgia  AOR.  They  used  chat  for  real-time  discussion  about  intelligence  and  force 
protection  information  with  the  Clayton  County  Sheriffs  Office,  Georgia  Intelligence  Sharing 
Analysis  Center  (GISAC)  and  other  local  law  enforcement  agencies.  Chat  allowed  AEOSI 
personnel  to  set  up  target  areas  to  work  sources  and  liaison  with  any  nearby  Air  Eorce  interests. 
Chat  is  used  for  planning  and  execution  because  of  its  ease  of  use. 

2.  National  Intelligence  Support  to  Joint  Operations 

The  US  Air  Eorce’s  55th  Wing  provided  national  intelligence  support  to  OEE  and 
OIE  with  their  RC-135  Rivet  Joint  (intelligence,  surveillance,  reconnaissance  platform)  aircraft. 
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Chat  was  vital  for  real  time  re-tasking,  target  sharing,  and  indieations  and  warning  for  ground 
elements.  More  effieient  than  voiee,  ehat  allowed  real-time  connectivity  with  everybody  at  once, 
including  in  joint  and  combined  forces  in  theater  and  reachback  to  various  stateside  agencies. 
The  most  common  use  of  chat  was  for  coordination  between  on-station  RC-135  Rivet  Joints,  the 
CAOC,  and  strike  aircraft  and  similar  coordination  with  ground  elements 
C.  ASSESSMENT 

There  are  many  reasons  warfighters  choose  to  use  chat.  When  answering  the  question  of 
why  chat,  many  attributes  were  used  (48  total).  Many  of  these  attributes  were  synonymous, 
while  others  grouped  well  into  subsets  with  each  other.  For  productive  discussion  we  wanted  to 
refine  the  reasons  given  for  chat  use  into  common  language,  so  we  combine  and  reduce  this  list 
to  the  top  five  reasons  for  use. 

1,  Faster 

Faster  applies  the  chat  users’  ability  to  request,  send,  and  receive  large  amounts  of 
information  in  real-time.  This  is  particularly  useful  for  tasking.  Tasks  sent  in  email  are 
immediately  available  for  the  recipient  unit  to  read  once  you  send  it.  Various  members  of  the 
unit  tasked  can  immediately  read  it  and  begin  task  clarification  and  refinement  within  their 
respective  functional  areas  using  chat.  Subordinate  and  supporting  units  can  also  monitor  these 
taskings  and  begin  coordination  and  parallel  planning,  compressing  the  planning  process  and 
ultimately  the  time  to  prepare  for  mission  execution.  Tasking  within  chat  happens  so  fast  that 
some  feel  the  chain  of  command  is  bypassed  because  very  often  when  higher  headquarters  tasks 
the  intermediate  headquarters,  the  tactical  units  already  see  the  tasking  and  begin  working. 
However;  many  units  leverage  this  speed  to  generate  operational  tempo,  particularly  in  the 
dynamic  counterinsurgent  and  disaster  relief  environments.  Users  report  that  chat  aids  in 
speeding  up  commanders’  OODA  Loops  (Observe,  Orient,  Decide,  Act). 

Units  are  re-tasked  fast  with  chat.  The  use  cases  demonstrated  this:  CAS  aircraft  in  the 
air,  UAVs,  Special  Forces  teams  -  these  can  all  be  dynamically  tasked  during  the  mission 
because  of  the  speed  generated  with  chat. 

Faster  also  applies  to  the  transmission  time  and  turn  around  times  of  other  systems. 
There  is  no  need  to  draft  a  radio  message,  hand  it  to  the  Radio  Watch  Supervisor,  and  wait  for 
the  operator  to  send  it.  Chat  does  not  need  to  be  read  line  by  line  like  a  radio  message  and 
copied  down  at  the  other  end.  You  do  not  have  to  retransmit  sections  of  the  message  or  read 
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back  sections  to  ensure  understanding  like  you  do  with  radio.  Even  if  two  aetuals  (commanders 
or  staff  officers)  are  talking  to  each  other  they  (or  somebody)  need  to  take  notes  as  grids,  times, 
target  numbers  and  the  like  are  passed.  This  is  unnecessary  with  chat,  generating  speed  and 
making  it  faster. 

Finding  a  phone  number,  dialing  it,  waiting  for  an  answer,  and  then  waiting  for  the 
person  you  aetually  want  to  talk  too  to  get  on  the  line  ean  be  long  proeess.  They  may  not  be 
there  requiring  you  to  work  with  somebody  else  or  even  leave  a  message.  If  they  are  there  you 
have  to  read  grids,  targets,  etc  back  and  forth  and  copy  them  down.  Again,  we  see  how  ehat 
generates  speed. 

Users  point  out  that  even  email,  file  transfer,  and  web-based  forms  are  too  slow.  They 
spend  time  looking  up  email  addresses  and  websites.  They  do  not  have  to  wait  on  the  distant  end 
to  read  their  requests  and  answer  baek.  This  is  slower  than  ehat.  Now  imagine  you  need  to  send 
the  information  to  ten  people  in  ten  different  units  or  ageneies. 

Chat  is  fast  beeause  it  generates  operational  tempo.  The  inereased  flow  of  information 
aeross  units,  funetions,  operational  boundaries,  and  serviees  inerease  speed  in  planning  and 
speed  in  exeeution. 

2,  Easy 

Easy  does  inelude  eonvenienee,  but  easy  helps  make  chat  fast.  With  chat  users  have  a  list 
of  who  is  in  the  room.  All  users  in  the  room  ean  read  the  ehat  thread  (unless  sent  private)  so 
users  do  not  need  to  look  up  email  addresses,  phone  numbers,  or  radio  network  ids. 

With  many  users  in  the  room,  no  multiple  radio  calls,  emails,  phone  ealls  need  to  be 
made.  Collaboration  is  the  norm  in  ehat,  no  need  to  eoordinate  it  like  white  boarding  sessions, 
eonferenee  ealls,  or  video  teleeonferenees.  The  ability  to  monitor  multiple  rooms  means  that  you 
ean  monitor  multiple  missions  of  various  units.  Users  feel  it  is  easy  to  build  and  maintain  their 
situational  awareness  this  way. 

Chat  uses  plain  language  that  is  easier  to  eonverse  in  and  understand  than  radio  proeedure 
for  example.  Chat  automatieally  ereates  a  reeord  of  the  eonversation  in  the  room  that  you  ean 
refer  baek  to  for  elarifieation  or  even  review  later  for  after  aetion  items.  Some  ehat  tools  ean  log 
their  eonversations  so  there  is  a  reeord  beyond  what  is  currently  displayed  in  the  room. 
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Users  said  that  chat  was  easier  than  other  communication  systems  like  tactical  radio 
networks,  or  secure  telephones  (STU-III/STE).  Some  noted  that  is  easier  to  type  in  Mission 
Oriented  Protective  Posture  (MOPP)  gear  with  a  gas  mask  than  talk  on  a  radio  or  phone. 

One  must  be  wary  of  the  convenience  factor,  because  chat  may  not  be  the  best  tool  for  all 
situations,  but  is  used  anyway.  For  instance,  a  request  that  a  user  needs  fdled  in  hours  or  days  is 
probably  better  sent  over  email  than  in  chat.  Inundating  chat  with  non-time  sensitive  information 
creates  clutter,  confusion,  and  makes  chat  slower  and  harder  to  use. 

3.  Availability 

This  attribute  is  a  composite  of  attributes  like  connectivity,  reliability,  stability.  Users 
found  (and  now  expect)  chat  to  be  there  when  other  C2  systems  are  not.  Further,  they  expect  the 
users  they  want  in  the  room  24  hours  a  day,  seven  days  a  week. 

When  users  enter  a  chatroom,  they  not  only  expect  other  users  within  their  unit  to  be 
available,  but  “everybody  else”  worldwide.  Users  cite  chat’s  ability  to  provide  a  collaborative 
C2  capability  between  multiple  garrison  (headquarters)  units  in  the  continental  US  and  deployed 
units  worldwide  in  a  single  tool.  This  global  capability  is  the  minimum  C2  capability  expected 
by  many  warfighters  interviewed.  Further,  users  expect  chat  to  provide  this  capability  over 
SIPRNFT,  high  side  (TOP  SFCRFT  networks),  and  even  on  Non-secure  Internet  Protocol 
Routed  Network  (NIPRNFT)  for  coalition  disaster  relief  operations  like  JTF-Katrina  or 
Operation  Unified  ASSISTANCE. 

Users  find  that  chat  is  available  when  other  C2  systems  are  not.  They  reported  that  chat 
was  the  only  form  of  communications  in  many  cases,  where  units  were  too  far  for  voice,  and  the 
available  transmission  systems  lacked  the  bandwidth  for  larger  C2  systems.  The  geographic 
dispersion  and  topography  of  Afghanistan  coupled  with  its  lack  of  infrastructure  is  a  perfect 
example.  Users  at  Forward  Operating  Bases  (FOBs)  in  Afghanistan  during  OFF  reported  having 
only  a  couple  phone  lines,  which  allowed  only  two  concurrent  phone  conversations,  but  provided 
them  the  ability  to  dial  in  with  chat  and  have  several  concurrent  chat  sessions. 

Even  when  there  is  more  robust  transmission  systems  support,  these  systems  lack  the 
bandwidth  for  many  workstations  with  larger  C2  systems,  so  warfighters  limit  the  number  of 
these  and  use  chat  to  fill  this  capability  gap.  Many  chat  tools  use  very  little  bandwidth  allowing 
more  users  to  use  chat  than  other  C2  systems;  these  tools  avoid  latency  and  timing  hits  on  the 
network.  When  the  network  experiences  issues  and  capabilities  degrade  (intentionally  or  not). 
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text-based  ehat  is  the  minimum  “gotta  have”  and  generally  available  long  after  the  other  C2 
systems  have  stopped  funetioning. 

Users  know  ehat  will  be  available  and  reliable  and  work  that  into  their  C4  plans.  When 
deployed,  the  first  data  system  up  in  many  eases  is  ehat.  Chat  is  then  used  to  eoordinate  bringing 
up  and  establishing  eonneetivity  with  the  other  C2  systems.  Chat  is  the  user’s  troubleshooting 
tool  of  ehoiee,  used  for  the  global  troubleshooting  of  SECRET  and  high  side  systems  in  theater, 
aeross  theaters,  and  even  with  eontraetors  stateside. 

4,  Efficient 

Users  like  how  ehat  allows  them  to  send  more  data  with  far  less  expenditure  of  time  and 
effort.  Eor  example,  various  reports  ean  be  sent  in  ehat  while  the  user  eontinues  to  look  at  the 
Common  Operating  Pieture  (COP);  map  software,  or  other  tools.  They  ean  monitor  ehat  while 
working  in  these  tools. 

Stated  before,  ehat’s  eapability  for  users  to  aeeess  multiple  rooms  and  have  eonversations 
with  multiple  people  with  no  extra  effort  is  a  eapability  strongly  embraeed  by  the  warfighter. 
Returning  to  sending  reports,  users  send  reports  to  large  groups  of  people  with  the  same  effort  it 
takes  to  send  it  to  one.  While  reports  ean  eertainly  be  sent  by  email,  ehat  allows  other  users  who 
may  not  doetrinally  need  the  report  but  are  monitoring  the  ehat  room  to  reeeive  it,  inereasing 
their  SA  at  no  additional  eost  in  time  or  effort.  Chat  allows  users  to  be  proaetive  rather  than 
reaetive  within  and  aeross  organizations.  One  should  note  that  this  eould  lead  to  the  dreaded 
overreaet,  or  proaetive  aetion  on  bad  information,  and  points  to  the  need  for  good  business  rules. 
Some,  organizations,  like  USCENTAE,  have  already  developed  ehat  business  rules. 

Users  like  how  ehat  faeilitates  understanding  with  written  text.  Time  and  effort  is  saved 
from  repeating  questions  beeause  you  have  it  written  before  you  -  if  information  is  missing  users 
ean  identify  it  faster.  This  persistenee  is  not  provided  as  effieiently  with  other  C2  means  that  use 
paper  logs  or  even  digital  methods  like  email  where  users  waste  time  rifling  through  email 
ehains. 

Chat  allows  a  division  of  labor  between  units  throughout  the  world.  Preparation  of  the 
foreeasts  by  the  METOC  in  the  use  eases  is  a  perfeet  example.  Deployed  units  drawing  upon 
other  units  globally  ean  experienee  eeonomies  of  seale. 

Teehnioally,  the  operation  of  ehat  should  breed  effieieney.  We  already  mentioned 
bandwidth  and  lateney,  but  with  ehat  there  is  no  retransmission  of  radio  traffie  or  stepping  on 
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each,  no  repeated  phone  calls  back  and  forth.  This  creates  efficiency  elsewhere;  reduced  radio 
traffic  freeing  voice  nets  for  urgent  tactical  traffic,  phones  free  for  when  needed,  less  load  on 
email  servers. 

5,  Required 

This  attribute  is  interesting  and  foreshadows  some  of  the  issues  in  the  next  section  on 
chat  risks.  If  most  business  is  done  in  chat,  then  you  need  chat  to  do  business.  Users  feel  that 
without  chat,  their  SA  would  be  diminished  and  information  dissemination  and  coordination 
would  be  a  struggle.  In  cases  where  chat  did  become  unavailable,  users  did  find  themselves 
behind  power  curve  trying  to  use  other  methods  (particularly  voice)  because  their  business 
practices  had  actually  changed  (note  that  the  business  rules  did  not  change  with  the  practices). 

Requirement  goes  beyond  capability  when  you  consider  combined  operations.  The 
HMCS  Toronto’s  experience  demonstrated  that  chat  is  required  during  coalition  operations,  but 
not  everybody  is  always  on  the  same  chat.  The  Canadian  ship’s  call  for  a  single  chat  was  echoed 
by  Expeditionary  Strike  Group  Six  (ESG-6).  The  ESG  noted  that  forces  under  tactical  control  of 
coalition  forces  should  use  a  collation  chat  solution  (in  this  case  CENTRIX)  where  you  would 
normally  use  SIPRNET-based  chat  (ESG-6  2005).  The  counterintelligence  use  case 
demonstrated  how  a  military  unit  was  required  to  use  chat  with  civil  authorities  to  prosecute  their 
force  protection  mission. 

The  attribute  required  goes  back  to  the  problem  statement  of  this  paper.  There  are 
numerous  chat  tools  in  use  that  do  not  interoperate.  There  are  major  issues  during  combined 
operations.  If  we  believe,  as  users  claim,  chat  is  a  required  tool  for  warfighting,  we  need 
representation  and  program  support  to  facilitate  standardization  and  interoperability. 

CHAT  RISKS 

Chat,  like  all  military  C2  systems,  has  associated  internal  and  external  risks  that  must  be 
mitigated  to  an  acceptable  level.  The  factors  creating  risk  are  technical,  organizational,  and 
related  to  Human  Systems  Integration  (HSI).  These  risks  affect  the  baseline  Information 
Assurance  (lA)  requirements  of  confidentiality,  availability,  and  integrity  set  forth  in  DoD 
Directive  8500.1:  lA  (2002)  and  DoD  Instruction  8500.2:  lA  Implementation  (2003). 

1,  External  Risks 
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The  external  risks  are  those  to  eritieal  infrastrueture  and  parallel  to  the  generalized 
threats  to  the  Global  Information  Grid  (GIG)  and  other  national  (eoalition  partners)  networks 
(JCS  and  DISA  2005).  The  peer  to  peer  aspeet  (P2P)  of  ehat  ineludes  risk,  and  was  banned 
initially  before  being  authorized  eonditional  to  adherenee  with  the  appropriate  lA  praetiees  and 
Designated  Approving  Authority  (DAA)  approval  (Wells  2004a  and  Wells  2004b).  This  does 
not  mean  the  risks  were  mitigated,  but  only  aeeepted. 

2.  Internal  Risks 

a.  Integrity 

Internal  risks  are  the  greatest,  with  75  -  80  pereent  of  all  network  attaeks 
and  loss  of  proprietary  or  elassified  information  attributed  to  internal,  authorized  users  (JCS  and 
DISA  2005).  Researeh  has  shown  ehat  use  ean  lead  to  a  group  phenomenon  termed  false  sense 
of  security,  where  things  happen  to  quiekly  in  virtual  eollaboration  and  lead  to  premature 
deeisions  (Wainfan,  Lynne  and  Davis  2004).  This  impaets  the  integrity  of  information  in  ehat. 
The  MET  Taetieal  Air  Control  Center  (TACC)  experieneed  information  integrity  issues  within 
ehat  rooms  during  OIF  ranging  from  erroneous  grid  eoordinates,  transposed  numbers  for  times, 
and  even  an  ineorreet  order  to  exeeute  a  Taetieal  Reeovery  of  Aireraft  and  Personnel  mission 
(TRAP)  (Glasgow  2003). 

b.  Confidentiality 

With  most  ehat  residing  on  the  SIPRNET,  eonfidentiality  is  less  at  risk  by 
external  diselosure  than  by  diselosure  to  or  laek  of  diselosure  from  internal  users.  Many  user  ids 
used  in  ehat  are  funetional,  making  it  diffieult  to  know  who  is  really  in  the  ehat  room.  Some 
eonsider  that  human  nature  ereates  risk,  with  users  lying  about  their  identity,  sharing  aeeounts, 
failing  to  log  out,  aeeount  eompromise,  and  somebody  looking  over  your  shoulder  or  even 
“sniffing”  your  eonversation  (JCS  and  DISA  2005).  Malieious  software  may  be  reeeived  and 
aetivated  by  users  if  eoming  from  a  “person”  they  are  eomfortable  with  in  ehat  (JCS  and  DISA 
2005). 

c.  Availability 

Availability  is  impaeted  by  several  faetors,  with  bandwidth  the  major 
faetor  affeeting  units’  ability  to  use  ehat,  partieularly  the  ehat  eapabilities  of  larger  eollaboration 
suites.  During  Operation  UNIFIED  ASSISTANCE,  initial  use  of  IWS  ehat  by  deployed 
METOC  teams  failed  due  to  insuffieient  bandwidth,  foreing  all  units  supporting  the  Joint 
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Operations  Area  Foreeast  (JOAF)  and  switehed  to  a  smaller,  less  bandwidth  intensive  ehat  tool 
(Hey  2005;  Symes  2005).  A  similar  instance  happened  to  CJTF-Haiti  METOC  personnel  from 
USSOUTHCOM  using  the  DOTS  chat  software,  which  failed  due  to  bandwidth  and  latency 
shortfalls  (Kampmeyer  2004).  The  Stryker  Combat  Teams  of  3rd  Brigade,  2ID  used  chat  in  Iraq 
to  great  effect;  however,  they  too,  suffered  bandwidth-related  availability  issues  (3rd  Brigade, 
2ID  2004). 

3.  Tactical  Information  Exchange  and  Situational  Awareness 

Finally,  chat  can  actually  affect  the  units’  tactical  operations  and  situational 
awareness.  The  Combined  Anti-Armor  Teams  (CAAT)  of  Weapons  Company,  Third  Battalion, 
Fourth  Marines  struggled  to  receive  important  information  in  Iraq.  Important  tactical 
information,  TICs,  be  on  the  lookout  (BOLO)  reports,  friendly  troop  movements,  and  more  was 
sent  in  chat,  not  tactical  radio  networks  leaving  those  units  without  chat  out  of  the  loop  (Butler 
2005a;  2005b).  Recent  research  into  human  performance  issues  for  supervisory  control  of  the 
Navy’s  new  Tactical  Tomahawk  missile,  reported  by  Cummings  (2005)  made  the  unexpected 
discovery  that  many  subjects  fixated  on  the  chat  interface  and  ignored  the  task  of  retargeting 
missiles  in  urgent  situations.  The  experiment  subjects  were  repeatedly  instructed  that  retargeting 
was  their  primary  mission;  however,  they  continued  to  fixate  on  chat  answering  all  queries 
before  the  retargeting  problems  (Cummings  2005).  The  Command,  Control,  Communications, 
Computers,  and  Combat  Officer  (C50)  of  the  USS  IWO  JIMA,  while  standing  watch  noted  that 
the  volume  of  chat  traffic  inundated  users  with  information.  This  information  deluge  consisted 
of  legitimate  traffic  and  spurious  requests  from  users  requesting  information  in  the  names  of 
higher  headquarters  units.  When  the  C50  started  calling  these  users  based  off  their  profile 
information,  he  discovered  they  were  lower  ranking  personnel  collecting  information  for  briefs 
and  reports.  In  most  cases  the  information  had  already  been  passed  and  chat  was  being  used 
because  it  proved  easier  to  ask  for  the  information  directly  than  look  it  up. 

Significant  research  opportunity  exists  looking  into  managing  the  risk  of  chat  use. 
Technical  solutions  abound,  but  standardization  and  the  ability  to  integrate  cross-domain  within 
our  own  forces,  let  alone  with  coalition  partners,  remain  problems  of  policy  and  organizational 
behavior.  Organizational  change  must  be  coupled  with  HSI  research  to  ensure  success.  Only  by 
addressing  risk  as  a  dependency  of  technical,  organizational,  and  HSI  issues  will  we  reach  an 
acceptable  level  of  risk  for  the  DAA. 
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REQUIREMENTS 

The  requirements  doeumentation  and  development  of  by  Eovito  (2006)  used  the 
capabilities-based  approaeh  ealled  for  in  eurrent  joint  doetrine  and  joint  aequisition.  The 
Capstone  Concept  for  Joint  Operations  (2005)  and  its  Joint  Operating  Concepts  (JOCs)  build  the 
bridge  between  the  National  Security  Strategy  and  the  National  Military  Strategy  and  future  joint 
capabilities  through  transformational  change  in  Doctrine,  Organization,  Training,  Material, 
Leadership  and  Education,  Personnel  and  Eacilities  (DOTMLPE).  The  Joint  Capabilities 
Integration  and  Development  System  (JCIDS)  process  is  a  capabilities-based  assessment  (CBA) 
composed  of  a  structured,  four-step  methodology  to  define  capability  gaps,  capability  needs,  and 
approaches  to  provide  functional  or  operational  capabilities  defined  in  the  JOCs  to  the  future 
joint  force  (CJCSI  2005;  CJCSM  2005). 

This  research  concentrated  on  the  definition  of  C2  capability  gaps  filled  by  chat  and 
identification  of  capability  needs  to  develop  a  set  of  warfighter  requirements.  This  top  down, 
systems  engineering  approach  focuses  on  interoperability  when  decomposing  the  chat  capability 
needs  of  DoD,  federal  and  local  agencies,  and  our  coalition  partners  into  requirements.  This  is 
crucial  because  while  many  organizations  listed  the  same  gaps  and  requirements,  they  had  very 
different  ideas  of  what  those  requirements  meant  to  them  (i.e.  a  bandwidth  austere  environment 
to  the  Navy  is  very  different  from  that  of  the  Air  Eorce).  The  explicitly  stated  quad-service 
requirements  and  selected  COCOM  and  OGA  requirements  are  summarized  in  appendices  one 
and  two  of  this  paper.  Development  of  a  single  set  of  joint  and  coalition  chat  requirements 
continues. 

CONCLUSION 

Chat  use  has  permeated  all  aspects  of  military  operations.  While  considered  an  ad  hoc 
“solution”  for  the  warfighter  filling  short  term  requirements,  chat  is  actually  changing  units’ 
business  practices,  while  the  business  rules  regarding  chat  are  not  necessarily  keeping  up.  This 
poses  the  question,  “does  chat  support  doctrine  making  warfighters  more  lethal,  or  does  chat 
supplant  doctrine,  allowing  corners  to  be  cut?”  We  must  establish  an  official  set  of 
requirements,  official  support,  and  official  sponsorship  for  chat. 
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TEXT-BASED  CHAT  REQUIREMENT  COMPARISON 

Requirement 

USN 

USMC 

USA 

USAF 

FUNCTIONALITY 

Participate  in  Multiple  Concurrent  Chat  Sessions 

X 

X 

X 

X 

Display  Each  Chat  Session  as  Separate  Window 

Persistent  Rooms  &  Transitory  Rooms 

X 

X 

X 

Room  Access  Configurable  by  Users 

X 

X 

X 

Automatic  Reconnect  &  Rejoin  Rooms 

X 

Thread  Population/Repopulation 

X 

X 

Private  Chat  “Whisper” 

X 

One-to-One  IM  (P2P) 

X 

User  Configured  System  Alerts 

X 

Suppress  System  Event  Messages 

X 

X 

Text  Copying 

Text  Entering 

Text  Display 

Text  Retention  in 

Workspace 

Interrupt  Sessions 

Foreign  Language  Text  Translation 

Naming  Conventions  Identify  Functional  Position 

X 

X 

X 

Multiple  Naming  Conventions 

X 

Multiple  User  Types 

X 

Distribution  Group  Mgmt  System  for  Users 

Date/Time  Stamp 

X 

X 

X 

Chat  Logging 

X 

X 

X 

X 

User  Access  to  Chat  Logs 

X 

D 

X 

INFORMATION  ASSURANCE 

Access  Control 

X 

PKI  Enabled  (DoD  CAC) 

X 

User  authentication  via  Active  Directory  and  LDAP 
ver3 

X 

Unique  ID  for  all  users  worldwide 

X 

Provide  Encryption 

X 

Multi-Level  Security  Operation 

D 

SCALABILITY 

Austere  Network  Operation 

X 

D 

X 

X 

Low  Overhead  Login  Process 

X 

Use  Client  Without  Server 

X 

Distributed  Architecture 

X 

X 

#  Concurrent  Chat  Sessions 

X 

#  Concurrent  Users 

X 

X 

X 

Specified  Quality  of  Service 

X 

INTEROPERABILITY 

DoD  Standards 

X 

X 

Multi-Platform  Clients 

X 

X 

Interoperate  with  Existing  Collaboration  Systems 

X 

X 

Interoperate  With  Office  Automation  Tools 

X 
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SELECT  COCOM  &  DISA  TEXT-BASED  CHAT  REQUIREMENT  COMPARISON 

Requirement 

JFCOM 

CENTCOM 

NORTHCOM 

DISA 

FUNCTIONALITY 

Participate  in  Multiple  Concurrent  Chat  Sessions 

X 

X 

X 

Display  Each  Chat  Session  as  Separate  Window 

X 

X 

Persistent  Rooms  &  Transitory  Rooms 

X 

Room  Access  Configurable  by  Users 

X 

Automatic  Reconnect  &  Rejoin  Rooms 

X 

Thread  Population/Repopulation 

X 

X 

Private  Chat  “Whisper” 

One-to-One  IM  (P2P) 

X 

X 

Off-line  Messaging 

X 

User  Configured  System  Alerts 

X 

Suppress  System  Event  Messages 

Text  Copying 

X 

Text  Entering 

X 

Text  Display 

X 

Text  Retention  in  Workspace 

X 

Interrupt  Sessions 

X 

Foreign  Language  Text  Translation 

X 

X 

File  Transfer 

X 

Portal  Capable 

X 

Web  Client 

X 

X 

Presence  Awareness 

X 

X 

Naming  Conventions  Identify  Functional  Position 

X 

Multiple  Naming  Conventions 

X 

Multiple  User  Types 

Distribution  Group  Mgmt  System  for  Users 

X 

Date/Time  Stamp 

X 

X 

X 

Chat  Logging 

X 

X 

X 

User  Access  to  Chat  Logs 

X 

X 

INFORMATION  ASSURANCE 

Access  control 

X 

X 

X 

PKI  Enabled  (DoD  CAC) 

User  authentication  via  Active  Directory  and 

LDAP  ver3 

Unique  ID  for  all  users  worldwide 

Provide  Encryption 

X 

X 

Network  Security  Tools 

X 

X 

Cross  Security  Domain  Functionality 

X 

SCALABILITY 

Austere  Network  Operation 

X 

X 

Low  Overhead  Login  Process 

Use  Client  Without  Server 

Distributed  Architecture 

#  Concurrent  Chat  Sessions 

#  Concurrent  Users 

Specified  Quality  of  Service 

INTEROPERABILITY 

DoD  Standards 

X 

Open  Standard 

X 

Multi-Platform  Clients 

X 

Interoperate  with  Existing  Collaboration  Systems 

X 

X 

X 

Interoperate  With  Office  Automation  Tools 
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INTRODUCTION 

•  Ad  hoc  “solutions”  for  the  warfighter 

•  Many  different  tools  (preferences) 

•  Shortterm  requirements  lack  joint 
interoperability 

•  Lack  of  official  support 

-  No  official  requirements 

-  No  official  support 

-  No  official  sponsorship 
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RESEARCH 


•  Use  Cases 

-  What? 

-Why? 

•  Risks 

-Acknowledge  technical 

-  Focus  on  organization,  human  nature 
situational  awareness 

•  Requirements 
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USE  CASES 


•  J3  Operations 

-  Multinational  Operations 

-  Disaster  Relief/Civii  Military  Operations  (CMO) 

-  Antiterrorism/Homeland  Defense 

-  Speciai  Operations 

-  UAV  Operations 

-  Targeting 

-  Ciose  Air  Support  (CAS) 

-  Combat  Recovery 

-  Medicai  Evacuation  (MEDEVAC) 

•  J2  Intelligence 

-  Counterintelligence  (Cl) 

-  National  Support  to  Joint  Operations 
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USE  CASES 


•  Why? 

-  Faster 

-  Easy 
-Availability 

-  Efficient 

-  Required 
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RISKS 


•  External  Risks  (GIG,  P2P) 

•  Internal  Risks 

-  Integrity 

-  Confidentiality 
-Availability 

•  Tactical  Information  Exchange  and 
Situational  Awareness 
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REQUIREMENTS 

•  Requirements  Documented 

-  Quad-Service 

-  COCOMS  (select) 

-DISA 

•  Methodology 

-  Capabilities  Based  Assessment  (CBA) 

-Joint  Capabilities  Integration  and 
Development  System  (JCIDS) 

-  Future  Joint  Force  and  Transformation 
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REQUIREMENTS 


•  Areas 

-  Functionality 

-  Information  Assurance  (lA) 

-  Scalability 

-  Interoperability 

•  Cross  Donnain 

-Addressed 

-  Policy  is  the  key  issue 
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CONCLUSION 

•  Chat  is  changing  business  practices 

-Are  business  rules  keeping  up? 

-  Facilitate  doctrinal  execution  or  cut  corners? 

•  The  Need: 

-  Official  Requirements 

-  Official  Support 

-  Official  Sponsorship 
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